home *** CD-ROM | disk | FTP | other *** search
/ BBS in a Box 12 / BBS in a box XII-1.iso / Files / Tele / Internet / UUPC 3.1b25.sit / Documentation / Troubleshooting < prev    next >
Encoding:
Text File  |  1992-01-28  |  6.5 KB  |  136 lines  |  [TEXT/ALFA]
  1. Troubleshooting uupc sessions
  2.  
  3. Symptom:  uupc can't place a phone call to your neighboring site.
  4.  
  5. Possible cause:  Systems file is malformed.  Re-read the documentation and
  6. check the file.  If necessary, run uupc with a debug level of 5, and watch
  7. the screen as uupc parses the lines in the file and tries to make sense of
  8. them.  You may be able to figure out where the problem lies.
  9.  
  10. Possible cause:  you have specified the HAYES dialer, and your modem is not
  11. Hayes-compatible.  Try using the DIR "dialer", which isn't a dialer at all...
  12. it simply opens a serial-port connection and then starts running the chat
  13. script.  You can use the chat script to dial your modem.
  14.  
  15.  
  16. Symptom:  uupc dials the phone, your neighbor's modem answers, but uupc
  17. reports "Login failed".
  18.  
  19. Possible cause:  the send/expect strings in the chat script are not correct.
  20. Run uupc with a debug level of 5, observe what uupc expects to receive from
  21. your neighbor's system and what it really receives, and edit your send/expect
  22. strings to suit.  You may need to add some delays, or change the expect
  23. timeout, or add some try-again strings.
  24.  
  25. Possible cause:  speed-switching problems.  You have configured the serial
  26. port to a higher speed than that of the modem-to-modem link (e.g. you specified
  27. 9600 in the Systems file, and the modem which actually answers speaks only
  28. at 2400 bits/second).  Your modem is reporting the actual speed of the
  29. connection in its CONNECT message (e.g. "CONNECT 2400").  Either uupc is
  30. switching its serial-port speed to match that of the CONNECT message, and
  31. the modem isn't (solution: specify the dialer as HAYES! or HAYES!options,
  32. rather than as HAYES or HAYES+options)... or, the modem is switching speeds,
  33. and uupc isn't (change your HAYES! dialer specification to HAYES or
  34. HAYES+options, or change your HAYES!options specification to include
  35. an option to instruct the modem not to switch speeds).
  36.  
  37.  
  38. Symptom:  uupc establishes a connection, but never says "Startup"
  39.  
  40. Possible cause:  uucp misconfiguration at your neighbor's site.  Run uupc
  41. with a debug level of 5, and make note of what your neighbor's system
  42. says after uupc logs in.  Take this information to your neighbor's
  43. sysadmin.
  44.  
  45. Possible cause: noisy phone lines.  The early stages of the uucp protocol
  46. negotiation are not protected by the 'g' protocol and can be disrupted
  47. by line noise. Try again.
  48.  
  49. Possible cause:  your connection to your neighbor's system is not to a
  50. hardwired serial port, but to a network terminal server.  The server is
  51. not passing data through to the system you're calling until it sees a
  52. carriage-return.  uucp 'g' packets don't have carriage returns.  Ask your
  53. neighbor sysadmin how to instruct the terminal-server to go into
  54. "download" or "transparent" or "push" mode, and add the necessary
  55. commands to your chat script.
  56.  
  57.  
  58. Symptom:  uupc gets through the Startup phase, and the conversation fails
  59. immediately thereafter:  either the phone hangs up, or uupc starts reporting
  60. "header checksum error" and disconnects due to an excessive error count.
  61.  
  62. Possible cause: You have specified a large-packet 'g' protocol connection,
  63. and are talking to a system which cannot construct large packets without
  64. scrambling the packets or dumping core and aborting.  Revert to a
  65. standard-sized-packet session (64 bytes), or try 128-byte packets.
  66.  
  67.  
  68. Symptom:  uupc gets through Startup phase, starts sending or receiving
  69. files, and the file transfer halts part way thorough one file.  The
  70. session finally ends in an excessive-error-count disconnection.
  71.  
  72. Possible cause: extremely noisy phone line is overwhelming the 'g'
  73. protocol's error-recovery capability.  Try a different phone line.
  74.  
  75. Possible cause: one of the modems involved in the communication is
  76. configured for XON/XOFF flow control, an XOFF character was transmitted
  77. as part of a 'g' protocol packet, and the modem has interpreted this as
  78. a "stop sending data" command.  Reconfigure the modems... the 'g'
  79. protocol is entirely incompatible with XON/XOFF flow control.
  80.  
  81. Possible cause: you have specified a larger-than-normal 'g' protocol
  82. window (e.g. 7 packets).  Your neighbor system has agreed to a larger window,
  83. but can't really handle it... your neighbor's serial-port buffers are
  84. overflowing.  Switch back to a 3-packet window.
  85.  
  86.  
  87. Symptom: files are transferred properly, but throughput is poor.
  88.  
  89. Possible cause: neighbor system is overloaded.  Try calling later.
  90.  
  91. Possible cause: noisy line, leading to many retransmissions.  Try calling
  92. later.
  93.  
  94. Possible cause: you are running LocalTalk, and its interrupts and SCC
  95. polling are causing your modem port to drop characters, leading to
  96. excessive retransmissions.  Turn off LocalTalk while running uupc, or
  97. switch to a lower serial-port speed.
  98.  
  99. Possible cause: you are running a standard 'g' protocol connection (3-
  100. packet window, 64-byte packets) over an MNP or V.42/V.42bis modem
  101. connection.  MNP or V.42 is slowing down the ACK packets enough to lead
  102. to protocol stalling.  Turn off MNP or V.42/V.42bis, or try a larger
  103. window or packet size.
  104.  
  105. Possible cause: you are communicating with a Mac/gnuucp system.  Mac/gnuucp
  106. (up through version 4.6 at least) supports only a one-packet window,
  107. and is limited to about 200 bytes/second of throughput no matter how
  108. fast your modems may be.  Install uupc 3.0 at the affected system.
  109.  
  110. Possible cause: you are transferring files using the 'f' protocol, over
  111. a connection which is not "almost error-free".  The entire file is being
  112. retransmitted several times.  Switch to the 'g' protocol, or use an
  113. error-correcting protocol such as MNP or V.42/V.42bis.
  114.  
  115.  
  116. Symptom: you instruct uupc to call "Sites with jobs pending" or "Per
  117. schedule file", and it doesn't call one or more sites which have jobs
  118. pending or which appear to be due for a call.
  119.  
  120. Possible cause: the time-of-day restrictions in the Systems file forbid
  121. calling the site(s) in question at this time.  Wait until later, or edit
  122. the Systems file and remove the time restrictions.
  123.  
  124. Possible cause: the entry in the Schedule file may be in error.  Check it
  125. and correct it if necessary.
  126.  
  127. Possible cause: one or more failed attempts to call the site(s) in question
  128. have triggered the failed-call fallback algorithm, which forbids calling
  129. a site for 5 minutes after the first failed call, 10 minutes after two
  130. failed calls, 20 minutes after three, and so forth.  Force a call to the
  131. affected system by selecting its name from the Call menu (this overrides
  132. the fallback algorithm), or add a specific fallback time to the appropriate
  133. line in the Systems file, or throw away the "ST.systemname" status file
  134. in the spool folder.
  135.  
  136.